a. Is there any policy regarding use of asyn:READBACK, as opposed to use of _RBV records?

The use cases are quite different. _RBV is used to indicate what the hardware currently is using. It does not modify the output record. asyn:READBACK updates the output record based on the readback. I have typically only used asyn:READBACK in specialized cases, for example the FileNumber in the file plugins, which can be autoincremented by the driver, or manually set by the user. For most parameters I don't like the driver to modify the output record. Having the output and readback be different can give the user an indication that something is wrong, whereas updating the output record could hide this problem.

b. The st.cmd file does not currently select a specific camera (it will select the default camera 0, i.e. whichever is the first detected). This is an issue because camera settings are loaded from the hardware on start-up.

I don't think many people are using ADPICam, so I think you will probably find a number of issues like this that have not been addressed yet. It would be great if you can test and improve the driver! I am currently using ADLightField rather than ADPICam, but ADLightField has its own issues, and I would be happy to know that ADPICam was a viable alternative.

The current software has a capability for selecting a camera (by it's enumeration order) from the AvailableCameras_RBV record.
This is a concern because the enumeration order is not guaranteed by the Princeton API.

It's more useful to select a specifc camera by it's serial number.
I've added that capability, used from the constructor.
And added it as a parameter used within st.cmd (0 selects the first available camera).

The AvailableCameras_RBV record is populated (with camera model) through the readEnum method.
If there is more than one identical camera model, this could be an issue.
What does Asyn do, if the enum strings are not unique?

I've prepended the camera serial number to the enum string.
This changes (in my case):
"ProEM-HS: 512B eXcelon-2" to
"#12546318 ProEM-HS: 512B e"
(The string is clipped because it's length exceeds MAX_ENUM_STRING_SIZE)

I don't understand the cause of this reported error:
2020/11/20 15:47:11.421 NDPluginDriver::createCallbackThreads error, queueSize=0 must be >= 1, setting to 1
2020/11/20 15:47:11.425 NDPluginDriver::writeInt32 ERROR, status=3, function=64, paramName=QUEUE_SIZE, value=0, connectedToArrayPort_=1
This doesn't seem to cause a problem.